\documentclass[12pt, a4paper]{scrartcl}

% packages
\usepackage[utf8]{inputenc}
\usepackage[ngerman]{babel}
\usepackage{scrpage2}
\usepackage[numbers,square]{natbib}
% other needed packages
\usepackage{graphicx, tocbasic, listings, color, colortbl, hhline, varwidth,
booktabs, footnote, hyperref, array, tabularx}

\makesavenoteenv{tabular}

% setting up listings
\definecolor{lightgray}{rgb}{0.95,0.95,0.95}
\definecolor{darkgray}{rgb}{0.8,0.8,0.8}
\definecolor{mypurple}{rgb}{0.76,0,0.61}
\definecolor{mydarkgreen}{rgb}{0,0.5,0}
\lstset{
	keywordstyle=\color{mypurple},
	identifierstyle=,
	commentstyle=\color{mydarkgreen},
	stringstyle=\color{blue}\ttfamily,
	backgroundcolor=\color{lightgray},
	basicstyle=\sffamily\scriptsize,
	breaklines=true,
	columns=fullflexible,
    numbers=left,
	numberstyle=\tiny,
	numbersep=5pt,
	stepnumber=2,
	frame=tb
}

%Koma-Script-Setups
\pagestyle{scrheadings}
\clearscrheadings
\ohead{\pagemark}
\ihead{\headmark}
\cfoot{}
\setheadsepline{.4pt}

% article informations
%\date{01. Dez. 2011}
%\author{Swen Priebe \& Johannes Raczek}
%\title{Bedrohungen, Risiken, Sicherheitsanforderung und -maßnahmen beim Cloud Computing}

\begin{document}

% Titelseite
\title{TitelTitelTitel}
\author{NameNameName}
\date{DatumDatuMDatum}

\begin{titlepage}
  \begin{center}
  	\vspace*{4em}
  
    {\small Fachhochschule Hannover - University of Applied Sciences and Arts\\
    Fakultät IV, Abteilung Informatik \par}
    
    \vspace*{4em}
    
    {\large\bfseries Master--Seminar \\
     \normalsize  IT--Sicherheit \par}
    
    
    \vspace*{3em}
   
    {\huge\bfseries Bedrohungen, Risiken, Sicherheitsanforderung und -maßnahmen beim Cloud Computing
    \par}
    
    \vspace{3em}
   
   	Verfasser \\
    {\Large Swen Priebe \& Johannes Raczek \par}
   
    \vspace{14em}
   
    \begin{tabular}{ll}
      Betreuer:    	 & Prof. Dr. Josef von Helden   \\
      Studiengang:   	 & Angewandte Informatik   \\
    \end{tabular}
    
    \vspace{2em}
    
    Dezembert $2011$
  \end{center}
\end{titlepage}


\thispagestyle{empty}
\pagebreak

% Römische Paginierung für Titel-Seite und Inhaltsverzeichnis
\renewcommand{\thepage}{\Roman{page}}

\vspace*{20em}
\noindent
\pagebreak
\tableofcontents
\pagebreak






\pagebreak



% Arabische Paginierung für den Text
\renewcommand{\thepage}{\arabic{page}}
\setcounter{page}{1}

\automark[subsection]{section}

\section{Einleitung \it \bfseries \tiny SP}\label{sec:einleitung}

\subsection{Motivation}\label{sec:einleitung:motivation}
Die Cloud scheint in diesen Tagen omnipräsent zu sein. Von der Fachpresse bis hin zu
wissenschaftlichen Arbeiten, findet sich das Thema \emph{Cloud Computing} fast an jeder zweiten
Ecke. Dabei war im Jahr 2002, als Amazon die \emph{Amazon.com Web Services} (AWS) launchte, von der
Cloud nie die Rede. Beworben als innovative Platform für die Webentwicklung, gedacht für Entwickler und
Webseitenbesitzer, wurde Amazon schon bald bewusst, dass sich hinter den eigenen, oftmals
ungenutzten Ressourcen, viel wirtschaftliches Potential versteckt. Heute bietet Amazon eine große
Anzahl unterschiedlichster Cloud Services an und AWS entwickelte sich zu einem weiteren finanziellen
Standbein. Es sollte daher auch nicht verwunderlich sein, dass viele Unternehmen auf diesen Zug
aufgesprungen sind. Hierbei nahm auch die Bandbreite an unterschiedlichsten Dienstleitungen deutlich
zu. So weisen z.B. Apple, Google und Microsoft heute ein umfassendes Portfolio an Cloud Services
auf, die sowohl für Privat- als auch viele Geschäftkunden interessant sind. Insbesondere klein- und
mittelständische Unternehmen, die über ein vergleichsweise kleines Kapital für eine eigene
IT-Infrastruktur verfügen, profitieren von dieser Entwicklung. 

Doch wo Licht ist, ist auch Schatten. So weisen Fachleute dies- und jenseits des Atlantiks auf
mögliche Gefahren des Cloud Computing hin, die in der allgemeinen Hype-Stimmung allzu häufig etwas
untergehen. Das Gefahrenbild reicht dabei von denkbaren Schwachstellen in den zugrundeliegenden
Technologien des Cloud Computing, bis hin zu inhärenten Problemen, mit der die unterschiedlichsten
Cloud Modelle zu kämpfen haben. Als Beispiel sei an dieser Stelle der mehrtägige Aufall vieler
Amazon Web Services in Nordamerika genannt, der sich im April 2011 ereignete. Viele populäre
Webseiten und Dienste waren entweder garnicht oder nur beschränkt aufrufbar. Der Ausfall war
letztendlich auf ein einzelnes Datenzentrum in Virginia zurückzufuhren und brachte viele
Geschäftskunden um ihre Einnahmen. Amazon entschuldigte sich und versprach Verbesserungen, um einen
solchen Vorfall in Zukunft vermeiden zu können. Das Beispiel macht zweierlei Dinge deutlich: zum
Einen zeigt es, dass viele Geschäftkonzepte ohne die Cloud wohlmöglich garnicht existieren würden,
zum Anderen verdeutlicht es aber auch die Abhängigkeit vieler Unternehmen und führt damit klar vor
Augen, wie wichtig der Sicherheitsaspekt im Cloud Computing doch ist. 

Dieser Artikel setzt sich mit möglichen und existierenden Risiken des Cloud Computing außeinander.
Hierbei gilt zu evaluieren unter welchen Bedingungen bestimmte Risiken hinnehmbar sind und welche
Präventivmaßnahmen tatsächlich vor bestimmten Bedrohungen schützen. Desweiteren stellt der Artikel
anhand theoretischer Beispiele und weiterführender Konzepte allgemeingültie
Sicherheitsanforderungen- und maßnahmen vor. 

\subsection{Aufbau}\label{sec:einleitung:aufbau}

\section{Einführung: Cloud Computing \it \bfseries \tiny SP}\label{sec:cc}
Dieses Kapitel stellt eine Einführung in das Thema Cloud Computing dar und umfasst wichtige
Grundlagen wie beispielsweise die Deployment Modelle\footnote{Siehe Kapitel
\ref{sec:cc:deploy}.}. Weiterhin werden die essentiellen Eigenschaften wie auch die Risiken einer
Cloud Infrastruktur beleuchtet.

Als Quellen kamen \cite{mkl-cloudsecprivacy-09, winkler-seccloud-11} und
\cite{m2s2-herrschercloud-10} zum Einsatz.

\subsection{Definition \& Eigenschaften}\label{sec:cc:def}
Der Name Cloud Computing deutet es fast schon an: eine Definition dieses nebulösen Themas ist
keine einfache Angelegenheit. Die Cloud ist keine Softwaretechnologie sondern ein Paradigma, in dem
virtuelle Ressourcen über ein Netzwerk zur Verfügung gestellt werden. Hierbei bedient sich eine
Cloud unterschiedlichster Technologien wie Virtuallisierung und nutzt geschickt entstehende
Synergieeffekte aus. Jede Cloud Infrastruktur weist dabei zumindest die folgenden Eigenschaften auf:
\begin{itemize}
  \item \textbf{\emph{Verteilte \& gemeinsam genutzte Ressourcen}}\\
  Der Cloud--Provider hält seine Ressourcen in einem sogenannten Ressourcenpool vor. Dieser
  Ressourcenpool wird gemeinsam genutzt und steht allen Kunden zur Verfügung. Im Normalfall gibt es
  keine dedizierten Ressourcen, die dauerhaft nur einem einzelnen Kunden zuzurechnen wären. Bereits
  bereitgestellte Ressourcen werden nach deren Nutzung zunächst Bereinigt\footnote{Ggf.
  vertrauliche Informationen des vorigen Nutzers werden entfernt, getätigte Anpassungen rückgängig
  gemacht.} und anschließen wieder dem gemeinsamen Ressourcenpool zugeführt.
  \item \textbf{\emph{Netzwerkgebunden}}\\
  Sämtliche Services (deu. Dienste) einer Cloud ruft der Kunde über standarisierte
  Netzwerkprotokolle auf. Somit kommt man der heterogenen Client--Landschaft entgegen.
  Weiterhin dienen Web--Frontends einer zentralen und einfachen Konfiguration der Cloud
  Infrastruktur \footnote{Als Beispiel sei an dieser Stelle die AWS Management Konsole genannt. Sie
  erlaubt eine bequeme Konfiguration der wichtigsten Amazon Web Services. Die Aufrufe finden
  entweder über \emph{SOAP} oder \emph{REST} statt}.
  \item \textbf{\emph{Massive Skalierbarkeit}}\\
  Die Cloud ermöglicht das Skalieren von Ressourcen im großem Ausmaß. Benötigt ein Kunde eine
  IT--Infrastruktur mit tausenden von Systemen, so muss auch die Cloud auf diese Systemanzahl
  skalieren können. Grundsätzlich exisitieren zwei Arten von Skalierungsmechanismen:
  \emph{vertikale} und {horizontale Skalierung} (siehe Abbildung \ref{}). Bei der veritaklen
  Skalierung wird die entsprechende Ressource in größerer Ausführung erneut bereitgestellt. Viele 
  Ressourcen (wie z.B. VMs) müssen zu diesem Zweck zunächst freigegeben\footnote{Hiermit ist das 
  \emph{Deprovisioning der Ressource gemeint.}} werden. Die dadurch entstehende Latenz kann unter 
  Umständen zu Problemen führen. Bei der horizontalen Skalierung wird die Last auf \emph{replizierte
  Ressourcen} verteilt.
  Einzelne Ressourcen werden entlastet und kümmern sich gemeinsam um die Lösung einer Aufgabe.
  Der sogenannte \emph{Loadbalancer} ist für eine effektive Lastverteilung\footnote{Effektiv kann
  u. A. eine vorausschauende Bereitstellung von Ressourcen bedeuten, um Latenzen zu verkürzen.}
  verantwortlich. Er gibt den Ton vor und weiß wann es notwendig ist, nach oben oder unten zu
  skalieren. Load--Balancing selbst ist ein umfangreiches Forschunggebiet für das in diesem Artikel
  kein Platz bleibt; für mehr Informationen zu diesem Thema sei daher auf den Anhang verwiesen.
  \item \textbf{\emph{Elastizität}}\\
  Wenn es um die Skalierung von Ressourcen innerhalb einer Cloud geht, liegt das Augenmerk auf der
  Elastizität. Die Ressourcen sollen vorallem schnell freigegeben und mindestens genauso schnell
  bereitgesllt werden können, um den Skalierungsmechanismus nicht auszubremsen. Das Hoch- und
  Runterskalieren geschieht in der Regel transparent und für den Kunden hat es den Anschein, ihm
  stünden schier unbegrenzte Ressourcen für seine Zwecke dar.
  \item \textbf{\emph{Autom. Bereitstellten von Ressourcen}}\\
  Durch geschicktes Monitoring besitzt die Cloud die Fähigkeit, Ressourcen automatisch
  bereitzustellen. Diese Funktionalität ist eine Notwendigkeit, da manuelles Skalieren im
  Cloud--Maßstab nicht realisierbar wäre. Der Automatismus kann über deskriptive Regelsprachen
  gesteuert werden. Sie ermöglichen Regeln mit (dynamischen) Tresholds, anhand derer die Cloud den
  Skalierzeitpunkt ermittelt. Das umfangreiche Monitoring sorgt desweiteren dafür, dass der Kunde
  lediglich für diejenigen Ressourcen zahlt, die er tatsächlich in Anspruch nahm
  (\emph{pay--per--use model}).
\end{itemize}

\begin{figure}[h]
\centering{
\scalebox{0.25}{\includegraphics{./img/scaling.jpg}}}
\caption[Skalierungsmechanismen]{Vertikale und horizontale Skalierung}
\label{figure:scaling}
\end{figure}

Cloud Computing ist demnach ein \emph{On-Demand-Lösungsansatz}, d.h. ein Provider (deu.
Anbieter) stellt dem Kunden im Bedarfsfall die benötigten Ressourcen in virtualisierter Form
bereit. Die Spanne reicht daben von Rechenressourcen, Speicher und Netzwerken bis hin zu
Betriebsystemen, Middlewares und komplexen Anwendungen. Der Nutzer erkauft sich auf diese Weise 
allerdings nicht nur das Nutzungsrecht, sondern im gleichen Atemzug auch die Expertise des 
Cloud--Providers. Eine Tatsache die gerade im Hinblick auf die Sicherheit Vorteile mit sich bringt.
Denn auch wenn Anbieter wie Amazon und Google nur mit Wasser kochen, können sie doch mehr in 
Sicherheit investieren als z.B. ein mittelständische IT--Unternehmen. Es ist daher auch nicht
verwunderlich, dass seit Amazons Pionierarbeit viele weitere Cloud Provider folgten.
Schließlich wächst der Markt weiterhin unaufhaltsam, da die Cloud den Unternehmen eine
leistungsstarke IT--Infrastruktur bietet und das bei einem Bruchteil der Kosten für eine
\emph{On--premise IT}\footnote{On--premise bedeutet, dass sich die Serversysteme auf dem Grundstück
der jeweiligen Unternehmung befinden. Im Gegensatz zu einem entfernten Rechen-- \& Datenzentrum
(wie es bei Public Clouds der Fall ist), behält die Unternehmung somit die volle Kontrolle über
Hard--, Software und sämtlichen Prozessen.}. Abbildung \ref{figure:ausgaben} verdeutlicht die
ständig steigenden Ausgaben für Cloud Services im Vergleich zu einer konservativen On--premise IT.

\begin{figure}[h]
\centering{
\scalebox{0.5}{\includegraphics{./img/cloud_ausgaben.png}}}
\caption[Weltweite IT--Ausgaben]{Weltweite IT--Ausgaben im Vergleich (2008/2012). Quelle:
\cite{mkl-cloudsecprivacy-09}}
\label{figure:ausgaben}
\end{figure}

\subsection{Rückbesinnung auf alte Werte}
Cloud Computing ist keine Revolution, vielmehr war es ein evolutionärer Prozess, der sich über
Jahrzente erstreckte. Angefangen bei Mainframes, deren Anschaffung nicht selten ein finanzieller
Kraftakt war, brachten die Minicomputer Kostenersparnis und eine einfachere Handhabe mit sich. Bald
schon prägten Serverlandschaften das Bild und mit ihnen kamen neue Probleme. Den auch wenn es sich
um homogäne Hardware handelte, die Konfiguration der einzelnen Rechner war oftmals nicht identisch
oder für die Domäne korrekt konfiguriert. Immer kürzere Updateintervalle für die verwendeten
Applikationen, inkonsistente Daten auf den einzelnen Servern und propriätere Eigenlösungen für
individuelle Probleme, erhöhten den Wartungsaufwand noch zusehens. Dies Änderte sich mit dem
Siegeszugs des Internets. Die neuen Schichtenarchitekturen erforderten allgemeingültige Standards,
deren Implementierungen nach und nach Eigenlösungen verdrängten. So wären die heutigen
servicebasierten Architekturen ohne Technologien wie \emph{Corba} oder \emph{Soap} garnicht denkbar.
Im Grunde genommen könnte man behaupten, dass die geringe Relevanz der Thin--Clients im Vergleich zu
den Applikationsservern, mit ihren zentralisierten Kontrollstrukturen, eine Rückbesinnung auf die
alten Werte der Mainframe--Ära ist. Dies gilt ganz besonders auch für Cloud--Infrastrukturen, die 
neben den zentralisierten Kontrollstrukturen mit einem Ressourcenpool und Elastizität aufwarten
können. Den Mainframes sind sie dabei in Punkten wie der massiven Skalierbarkeit, dem Preis oder
der Fehlertolleranz --- bedingt durch die notwendige Redundanz innerhalb einer Cloud --- überlegen. 
Entlang einer imaginären Zeitachse veranschaulicht Abbildung \ref{figure:dev} die Entwicklung vom
Mainframe zur Cloud und nennt wichtige Technologien und Ansätze zum jeweiligen Meilenstein sowie
deren Auswirkung auf die Sicherheit.

\begin{figure}[h]
\centering{
\scalebox{0.65}{\includegraphics{./img/cloud_dev.png}}}
\caption[Entwicklungen]{Entwicklungen und deren Auswirkungen auf die Sicherheit. Quelle:
\cite{winkler-seccloud-11}}
\label{figure:dev}
\end{figure}
 
Zusammen mit den grundlegenden Eigenschaften einer Cloud\footnote{Siehe Kapitel \ref{sec:cc:def}.},
die sie vom Mainframe Modell abhebt, stellt sich zurecht die Frage, wieso der Paradigmenwechsel
nicht viel früher stattfand. Die Antwort ist recht profan: viele Kerntechnologien\footnote{Kapitel
\ref{sec:cc:infrastructure} wirft u. A. ein Licht auf diese Technologien.} des Cloud Computing wie
die Virtualisierung von Betriebssystemen und Netzwerken waren noch nicht weit genug gediehen und die
notwendige Bandbreite um effektiv mit Services einer Cloud zu arbeiten, war erst mit der
flächendeckenden Verbreitung der Breitbandnetze gegeben.

\subsection{Eckpfeiler des Cloud Computing}\label{sec:cc:infrastructure}
Hinter einer Cloud--Infrastruktur verbirgt sich ein Konglomerat vieler Technologien, die erst im
Zusammenspiel die Anforderungen an eine Cloud erfüllen. Das Buch \cite{winkler-seccloud-11} wagt
eine Kategorisierung die nachfolgend aufgelistet ist:

\begin{itemize}
  \item \textbf{\emph{Infrastruktur}}\\
  Jede Cloud--Infrakstruktur setzt sich aus einer Ansammlung an Hardwarekomponenten zusammen.
  Typischerweise sollten diese den Ansprüchen im Cloud--Umfeld genügen. Hierzu zählen vorallem die
  Skalierbarkeit und Sicherheit --- letzteres nicht zuletzt dem gemeinsam genutzten Ressourcenpool
  geschuldet. Der CSP sollte die schiere Anzahl an Server--, Speicher-- und Netzwerkkomponenten
  vorrausschauend wählen, um nicht bereits bei der Infrastruktur gegen besonders anspruchsvolle
  \emph{Service Level Agreements} (SLAs) klein beigeben zu müssen.
  \item \textbf{\emph{IP--basierte Netzwerke}}\\
  Das Netzwerk ist der Mörtel im Cloud Computing. Ressourcen, die Cloud--Komponenten
  selbst, als auch sämtliche Nutzer, sind über das Netzwerk mit der Cloud verbunden. Um dabei die
  Sicherheit von Anwendungen und Daten zu gewährleisten, werden oftmals VLANs\footnote{Umfassende
  Informationen finden sich unter:
  \url{http://standards.ieee.org/getieee802/download/802.1Q-2003.pdf}.} verwendet. Sie schaffen ein
  virtuelles Overlay über das eigentliche, physische Netzwerk und sind somit in der Lage, den
  Datenverkehr von einzelnen Nutzergruppen abzuschotten. Nicht selten finden sich gar physisch
  getrennte Netze in einer Cloud Infrastruktur wieder. Jedes Netzwerk verbindet nur Komponenten
  eines gemeinsamen \emph{Vertrauensbereiches}. Exemplarisch sei hier die Trennung vom
  administrativen Kontrollfluss und dem Datenverkehr normaler Cloud--Nutzer genannt. 
  
  Auch die Dimensionierung und die Konfiguration der Switches und Router gilt es zu bedenken. Sie
  müssen auch zu Stoßzeiten dem Nutzeransturm gewachsen sein und dürfen nicht zum sogenannten
  \emph{Single Point of Failure} (SPoF) werden, der das Kartenhaus Cloud zum einstürzen bringt.
  \item \textbf{\emph{Virtualisierung}}\\
  Es ist insbesondere die Virtualisierung, der die Cloud ihre Elastizität und Ausfallsicherheit
  verdankt. Durch die Paritionierung der physischen Ressourcen in virtuelle Teilstücke, schafft die
  Virtualisierung nicht nur das nötige Maß an Flexibilität\footnote{Zur dynamischen Bereitstellung
  und anschließender Freigabe von Ressourcen.}, sondern trägt auch zur Sicherheit bei. Anhängig von
  der Virtualisierungtechnologie\footnote{Dem Virtualisierunggrad nach \emph{Vollvirtualisierung},
  \emph{Paravirtualisierung} und \emph{Betriebssystemvirtualisierung}.}, verkleinert sich nämlich
  die Angriffsfläche\footnote{Möglichkeiten die einem Angreifer zur Verfügung stehen,
  Schwachstellen auszunutzen und tatsächlichen Schaden anzurichten.} auf das jeweilige
  Gastbetriebssystem. Die Laufzeitumgebungen bilden \emph{Sandboxes}, die virtuelle Maschinen (VMs)
  der einzelnen Cloud--Nutzer recht effektiv voneinander isolieren. Diese Vorteile haben dafür
  gesorgt, dass heutzutage Cloud Infrastrukturen auf Grundlage von Virtualisierungstechnologien
  überwiegen. Applikationen welche selbst Cloud--Konzepte in ihrer Architekturen umsetzen sind
  dennoch vereinzelt anzutreffen. So sind z.B. Anwendungen, die mit Google's
  Entwicklungsumgebung \emph{AppEngine}\footnote{Für mehr Infromationen siehe:
  \url{http://code.google.com/intl/de-DE/appengine/}.} geschrieben worden, bereits sehr
  Cloud--ähnlich --- auch wenn jene Applikationen am Ende meistens in virtualisierten
  Cloud--Umgebungen laufen.
  \item \textbf{\emph{Software}}\\
  Kapitel \ref{sec:cc:def} sprach kurz über den \emph{Load--Balancer}. Es handelt sich in der Regel
  um ein Stück Software, dem eine wichtige und komplexe Aufgabe zu teil wird. Wichtig, weil nur mit
  korrektem Load--Balacing jedem Serviceaufruf auch wirklich die nötigen Anwendungsinstanzen
  gegenüberstehen und komplex deshalb, da der Balancer einen umfassenden Überblick auf den
  \emph{Ist--Zustand} der Cloud benötigt. Das White Paper \cite{m2s2-herrschercloud-10} spricht hier
  von der \emph{dynamischen Steuerebene}, die den Daten-- und Kontrollfluß innerhalb der Cloud
  interpretiert und entsprechend handelt.
  
  Der Load--Balancer zeigt, wie kritisch der Punkt \glqq Software\grqq{} für den erfolgreichen
  Betrieb einer Cloud tatsächlich ist. Vom Management der gesamten Infrastruktur, über die
  Entwicklung der \emph{Cloud Services}, die notwendige Automatisierung vieler
  Cloud--Mechanismen, bis hin zur Durchsetzung sämtlicher Policies und damit auch der \emph{Services
  Level Agreements} (SLAs); alles steht und fällt mit der Qualität der Software.
  \item \textbf{\emph{Service Interfaces}}\\
  Um die Cloud Services nutzen zu können, muss der Kunde des Cloud Anbieter die
  dazugehörigen Schnittstellen kennen. So eignet sich beispielsweise SOAP in Kombination mit
  \emph{WSDL}, um den Serviceaufruf klar zu definieren und damit u. A. die SLAs durchzusetzen.
  Desweiteren ist die Qualität und die Bandbreite an Service Schnittstellen ein wichtiger
  Wettbewerbsfaktor für den Cloud Anbieter, schließlich senkt ein ergonomisches Web--Frontend zum
  Management der Cloud Infrastruktur und eine intuitive Handhabe des Service--Portfolios die
  Migrationsschwelle potentieller Kunden.
\end{itemize}

\subsection{Service Modelle}\label{sec:cc:service}
Im Cloud Computing gibt es drei wesentliche Service Modelle: \emph{Software--as--a--Service}
(SaaS), \emph{Platform--as--a--Service} (PaaS) und \emph{Infrastructure--as--a--Service} (IaaS).
Ihrer Bedeutung entsprechend spricht man auch vom \emph{SPI Modell}.

\begin{figure}[h]
\centering{
\scalebox{0.55}{\includegraphics{./img/service-model.png}}}
\caption[SPI Modell]{Das SPI Modell. Quelle:
\cite{winkler-seccloud-11}}
\label{figure:spi}
\end{figure}

Wie Abbildung \ref{figure:spi} illustriert, bilden die Technologien des Cloud
Computing\footnote{Siehe Kapitel \ref{sec:cc:infrastructure}.} die Basis für die Cloud Services und
deren Bereitstellung. Das SPI Modell spielt hierbei eine zentrale Rolle; so bezeichnet die
\emph{Cloud Security Alliance}\footnote{\url{https://cloudsecurityalliance.org/}} IaaS als Grundlage
aller Cloud Services, wobei PaaS auf IaaS aufsetzt und SaaS wiederrum auf PaaS. In diesem
Zusammenhang schreibt die Alliance:
\begin{quote}
\glqq In this way, just as capabilities are
inherited, so are information security issues and risk. It is important to note
that commercial cloud providers may not neatly fit into the layered service
models. Nevertheless, the reference model is important for relating real-world
services to an architectural framework and understanding the resources and
services requiring security analysis.\grqq{}
\end{quote}
Demnach können die einzelnen Service Modelle sowohl \emph{unabhängig} voneinander als auch
\emph{geschichtet} vom CSP angeboten werden (wie Abbildung \ref{figure:spi} ebenfalls anschaulich
verdeutlicht). Hierbei besitzt der Cloud--Nutzer in der untersten Schicht (IaaS) mehr Kontrolle,
trägt aber auch mehr Eigenverantwortung und benötigt zudem noch mehr Know-how. Diese Kontrolle gibt
er mit Paas und stärker noch mit SaaS zunehmend an den CSP ab, muss sich dafür aber auch weniger um
die Services kümmern.

Doch was genau verbirgt sich hinter SaaS, PaaS und IaaS? Die nachfolgende Liste gibt Aufschluss:

\begin{itemize}
  \item \textbf{\emph{Software--as--a--Service}}\\
  SaaS ermöglicht es dem Kunden komplette Anwendungen zu nutzen, die der CSP auf seiner Cloud
  Infrastruktur bereitstellt. Der Kunde erwirbt die Anwendungen nicht, sondern zahlt lediglich für
  deren Nutzung (pay--per--use) oder für einen festgelegten Zeitraum, in dem der Kunde beliebig oft
  von den Anwendungen Gebrauch machen kann. Der Kunde erhält so stets die aktuellste Version und
  muss sich nicht selbst um das Management oder das Hosting der Anwendung kümmern, was sowohl Kosten
  als auch Personal einspart. Währenddessen erhält der CSP mehr Kontrolle über die Nutzung und
  Verbreitung seiner zur Verfügung gestellten Software. Die Kunde besitzt nur eingeschränkte
  Konfigurationsmöglichkeiten und hat keinerlei Kontrolle über die darunterliegende Cloud
  Infrastruktur.
  
  Ein weiteres Unterscheidungsmerkmal zwischen SaaS--basierten und traditionellen Anwendungen ist
  die Anzahl der möglichen Nutzer. Während \emph{Google Docs} tausende von Nutzern gleichzeitig
  unterstützt, muss \emph{Microsoft Word} nur eine verhältnismäßig kleine Benutzergruppe bedienen.
  \item \textbf{\emph{Platform--as--a--Service}}\\
  Der CSP bietet seinen Kunden eine Entwicklungsumgebung als Service an, mit der umfangreiche
  Webanwendungen erstellt werden können. Die zuvor bereits erwähnte AppEngine von Google ist eine
  solche Umgebung. Toolkits und durchdachte APIs vereinfachen die Entwicklung auch für weniger
  versierte Programmierer, so dass hochspezialisierte Fähigkeiten keine Notwendigkeit mehr sind.
  Einzelne Entwickler und kleine Unternehmen profitieren zudem von der Tatsache, dass die fertig
  entwickelten Anwendungen in den Rechenzentren des CSP gehostet werden. Auf diese Weise spart sich
  der Kunde eine eigene IT--Infrastruktur ein. Es gehört an dieser Stelle jedoch erwähnt, dass
  bedingt durch die oftmals propriäteren APIs der CSPs, die entwickelten Anwendungen nicht
  ohne Weiteres auf die Cloud Infrastruktur eines anderen Anbieters migrierbar sind. Man spricht vom
  \emph{Cloud Lock--in}, ein Thema mit dem sich Kapitel \ref{} genauer beschäftigt. 
  
  Im PaaS Modell zahlt der Kunde für das Hosten seiner Anwendungen und ggf. auch für die
  Nutzung interner Cloud Services sowie der Entwicklungsumgebung. Er hat größtenteils die Kontrolle
  über die deployten Anwendungen und kann i. d. R. die Laufzeitumgebung konfigurieren.
  \item \textbf{\emph{Infrastructure--as--a--Service}}\\
  Das IaaS Modell ermöglicht es dem Kunden eine virtuelle IT--Infrastruktur aufzubauen. Hierzu
  stellt der CSP Management--Schnittstellen zur Verfügung, über die VMs, Speicher und weitere
  Ressourcen bereitgestellt und verwaltet werden können. Der Kunde hat die größtmögliche Kontrolle
  über die Handhabe seiner Daten (inklusive VM--Images) und kann beliebige Anwendungen auf den
  VMs ausführen. Bezahlt wird wie schon im SaaS Modell nach dem Pay--per--Use--Prinzip und in
  Abhängigkeit der gewählten VM--Instanztypen. Als Beispiel bietet Amazon's EC2 eine Reihe
  unterschiedlicher Instanztypen\footnote{Für mehr Informationen siehe:
  \url{http://aws.amazon.com/de/ec2/instance-types/}.} an, die wiederum in Gruppen sortiert sind.
  Die Spanne reicht von der \emph{Micro Instances} Gruppe, bis hin zur \emph{Cluster Compute
  Instances} Gruppe, zwischen denen eine gewaltige Leistung-- und Preissdifferenz liegt. 
\end{itemize}

\subsection{Deployment Modelle}\label{sec:cc:deploy}
Ein Blick zurück auf die Grafik aus Abbildung \ref{figure:spi} wirft eine weitere Frage auf: wer
zeigt sich für die notwendige Infrastruktur verantwortlich, die das Cloud Computing überhaupt erst
ermöglicht? Betrachtet man die vielzahl an öffentlich zugänglichen Cloud Services, so handelt es
sich dabei im Regelfall um einen Third--Party Anbieter. Das korrespondierende Deyploment Modell wird
\emph{Public Cloud} genannt. Doch nicht immer bietet sich eine Public Cloud an. Es folgt daher eine
Auflistung der bekannten Deployment Modelle:
\begin{itemize}
  \item \textbf{\emph{Public Cloud}}\\
  Eine Public Cloud bietet der Öffentlichkeit Cloud Services an. Sie wird von einem Third--Party
  Anbieter geführt und setzt sich aus einem oder meheren Datenzentren zusammen. Für die vielen
  Nutzer der Cloud Infrastruktur herrscht oft ein Gefühl der Ortungebundenheit vor, weil i. d. R.
  nicht ersichtlich ist, wo genau die in Anspruch genommenen Services tatsächlich ausgeführt werden.
  Nur der Anbieter hat physischen Zugriff auf die Cloud und zeichnet sich damit allein für die
  angebotenen Services und die Sicherheit der Kundendaten verantwortlich.
  \item \textbf{\emph{Private Cloud}}\\
  Besonders sensible Daten und High--Security--Anwendungen, die nicht einer Public Cloud anvertraut
  werden können, eignen sich für eine Private Cloud. Im Gegensatz zur Public Cloud wird die Private
  Cloud von ein und dem selben Unternehmen geführt und gemanaged. Die Literatur spricht auch gerne
  von der \emph{internen} Cloud, da diese dem Unternehmen gehört. Zusätzlich wird zwischen
  \emph{on--premise}/\emph{dedicated} und der \emph{managed} Private Cloud unterschieden. Erstere
  wird in einem Datenzentrum des Unternehmens selbst gehostet, während Letztere von einem
  Third--Party Anbieter im Auftrag des Unternehmens verwaltet wird.
  \item \textbf{\emph{Community Cloud}}\\
  Die Community Cloud kann als eine weitere Variante der Private Cloud angesehen werden. Der
  entscheidene Unterschied liegt darin, dass nun mehrere Unternehmen mit einem gemeinsamen
  Geschäftsinteresse die Cloud Infrastruktur teilen. Sie dient also dem Zweck einer bestimmten
  Gemeinschaft --- daher auch der Name.
  \item \textbf{\emph{Hybrid Cloud}}\\
  Eine Hybrid Cloud setzt sich aus mindestens zwei Clouds zusammen, die jeweils einem \emph{anderem}
  Deployment Modell folgen. Das gängiste Beispiel ist eine Hybrid Cloud aus Public und Private
  Cloud. Ein Unternehmen könnte z.B. nichtkritische Daten in eine Public Cloud auslagern oder eigene
  Anwendungen Lasttest unterziehen, die mit den begrenzten Ressourcen der eigenen Cloud
  Infrastruktur nicht möglich wären.
\end{itemize}

Für Unternehmen gilt es oftmal abzuwägen, welches Deployment Modell man schließlich folgt. Risiken
und Kosten müssen analysiert und mit den Security Policies sowie SLAs in Einklang gebracht werden.
Kapitel \ref{} setzt sich mit dieser Problematik auseinander.

Zu guter Letzt stellt Abbildung \ref{figure:deployment} die unterschiedlichen Deployment Modelle
noch einmal simpel grafisch aufbereitet vor.

\begin{figure}[h]
\centering{
\scalebox{0.75}{\includegraphics{./img/deployment-modelle.png}}}
\caption[Deployment Modelle]{Deployment Modelle im Überblick.}
\label{figure:deployment}
\end{figure}

\include{risikomanagement}

\section{Die Cloud und ihre Risiken \it \bfseries \tiny SP}
Wie die Einleitung dieses Artikels bereits andeutete, weist das Cloud Computing einige inhärente
Risiken auf, die der Ansatz zwar nicht alleine für sich beanspruchen kann, die von Kritikern bei
jeder Gelegenheit aber stets genannt werden. Hierzu zählt z.B. das Problem der Daten-- und
Identitäsabschottung in einer Public Cloud, gerade im Hinblick auf eine der grundlegenden
Eigenschaften einer Cloud, nämlich den \emph{gemeinsam genutzten} Ressourcenpool. 

Dieses Kapitel soll --- einleitend für alle kommenden Kapitel zum Thema \glqq Sicherheit\grqq{} ---
einige ausgewählte Risiken und Bedrohungen im Cloud--Umfeld näher vorstellen. Als Vorlage dient das
Buch \cite{winkler-seccloud-11}.

\subsection{Überblick}
Viele Bedrohungen lassen sich schon mit relativ simplen Sicherheitskontrollen entschärfen.
Zunächst ist es jedoch notwendig, möglichst alle denkbaren Bedrohungen aufzuspüren. Eine
umfangreiche \emph{Gefahrenanalyse} ist daher anzuraten, ihr Erfolgt hängt aber stark von den
eigenen Annahmen und dem geplanten Softwaredesign ab. 

Im Vorweld erweist sich die Auflistung häufiger Sicherheitsbedenken als hilfreich. Je nach
Deployment und Service Modellen, Security Policies, der Gesetztgebung und den SLAs, sind bestimmte
Bedrohungsbilder nämlich zu vernachlässigen\footnote{Kapitel \ref{} setzt sich detailliert mit der
Bewertung von Risiken auseinander.}. Die nachstehende List geht kurz auf einige der häufigsten
Sicherheitsbedenken im Cloud Computing ein:

\begin{itemize}
  \item \textbf{\emph{Netzwerkverfügbarkeit}}\\
  Das Netzwerk muss den Anforderungen an die jeweilige Cloud Infrastruktur genügen.
  Netzwerkkomponent sollten redundant und ausreichend dimensioniert sein, um Cloud--Clustern
  untereinander und Nutzern stets Zugriff aus die Cloud Services zu ermöglichen. Unzureichende
  Bandbreite und etwaige Verbindungsprobleme führen im schlimmsten Fall zum \emph{Denial of Service}
  (DoS) und gefährden damit die Ge\-schäfts\-tätigkeit des Cloud Anbieters und seiner Kunden.
  \item \textbf{\emph{Zuverlässigkeit der Cloud Anbieter}}\\
  Kunden müssen sich auf den Cloud Anbieter bzw. CSP verlassen können, insbesondere wenn ihre
  Geschäftsprozesse von Cloud Services abhängen. Anerkannte Zertifikate helfen, den passenden
  Anbieter aufzufinden. Bereits angesprochene Probleme wie der \emph{Cloud--Lock--In}, müssen
  bei der Wahl des CSP, gerade für PaaS und IaaS Modelle, berücksichtigt werden. 
  \item \textbf{\emph{Geschäftsprozesse im Problemfall}}\\
  Probleme kommen stets unerwartet. Der Ausfall eines Datenzentrums durch einen Brand, die
  Beschädigung von Telekommunikationskabeln\footnote{Im Jahr 2010 wurde durch einen Schiffsanker
  das \emph{SEA-ME-WE 4} Tiefseekabel durchtrennt. Die Folge war ein zum Teil massiver Einbruch der
  Bandbreite zwischen Europa, Afrika und Asien.}, Hard-- und Softwarefehler --- nur drei Beispiele
  unter vielen. Unter diesen Umständen erwartet der Kunde dennoch größtmögliche Sicherheit
  für seine Geschäftsprozesse. Sie sollen weiterhin laufen, auch wenn der CSP mit schwerwiegenden
  Problemen zu kämpfen hat. Anbieter wie Amazon versichern eine Verfügbarkeit von über 99 Prozent,
  gesichert durch strikte Sicherheitsmaßnahmen und redundante Daten, die in Datenzentren
  über dem gesamten Globus verteilt liegen.
  \item \textbf{\emph{Sicherheitsvorfälle und Transparenz}}\\
  Ereignet sich ein Sicherheitsvorall, ist guter Support des CSP unabdingbar, um Informationen über
  den Vorfall selbst und die wahrscheinliche Schadensgröße einzuholen. Der Kunde besitzt nur
  geringfügige Optionen, Sicherheitslücken zu untersuchen und ist somit auf die Analysen des
  Anbieters angewiesen. Transparenz im Bezug auf die Realisierung der Cloud Infrastruktur und die
  internen Vorgänge des CSP hilft dem Kunden außerdem zu verstehen, wie mit Sicherheitsaspekten
  umgegangen wird und ob der Anbieter den gestellten Ansprüchen Sorge trägt. 
  \item \textbf{\emph{Kontrollverlust}}\\
  Unternehmungen, die keine eigenen Cloud Infrastruktur ihr Eigen nennen, geben unweigerlich
  Kontrolle an den gewählten Cloud Anbieter ab. Vertrauliche Daten werden redundant in verteilten
  Datenzentren gespeichert, ggf. mit Informationen Dritter vermischt und ohne umfassende (physische)
  Kontrollmöglichkeiten für den Kunden verarbeitet. Wie in Kapitel \ref{sec:cc:service} besprochen,
  entscheidet das Service Modell in Public Clouds über den Grad der Eigenkontrolle, die ein Kunde
  über seine Applikationen und Daten hält.
  \item \textbf{\emph{Neue Risiken und Schwachstellen}}\\
  Täglich erblicken neue Schwachstellen das Licht der Welt. Ganz besonders große und komplexe
  Systeme sind hiervon betroffen. Hinzu kommt die Annahme vieler Fachleute, dass die Verknüpfung von
  Hard-- und Softwaretechnologien aller Art, wie es in der Cloud der Fall ist, auch neue Risiken
  hervorbringt, die in den einzelnen Technologien nicht anzutreffen waren. Die Menge an
  Schwachstellen in einer Cloud sei größer als die Summe ihrer Teile, so die Hypothese. Eine gängige
  Maßnahme hiergegen ist die Praxis des \emph{Layered Defense}. Multiple Sicherheitsmechanismen die
  verschachtelt zum Einsatz kommen, sollen zusätzlichen Schutzt gegen gängie Angriffe wie
  \emph{Command Injection} oder \emph{Buffer--Overflows} bieten.
  \item \textbf{\emph{Gesetzeskonformität und weitere legale Aspekte}}\\
  Bei diesem Punkt handelt es sich um ein äußerst umfangreiches Themenfeld. Es kann aus vielerlei
  Gründen in dieser Arbeit nur oberflächlich behandelt werden. Neben SLAs mit dem Kunden ist
  vorallem auch der rechtliche Aspekte bei der Umsetzung bestimmter Services von größster
  Wichtigkeit. Der \emph{Health Insurance Portability and Accountability Act} sieht beispielsweise
  eine ganze Armada umfassenster \emph{Regularien} vor, wie Daten im Gesundheitswesen transportiert
  und gespeichert werden sollen. Hinzu kommen Fragen, die die Handhabe der Informationen von Kunden
  betreffen. Was passiert z.B. mit Daten ehemaliger Kunden\footnote{Ggf. existieren gesetzliche
  Vorschriften oder Policies, die eine Löschung der Kundendaten regeln.} und wie wird beim Transport
  von Informationen über Landesgrenzen hinweg verfahren (\emph{PATRIOT Act}\footnote{Für mehr
  Informationen siehe: \url{http://de.wikipedia.org/wiki/USA_PATRIOT_Act}.}).
\end{itemize}

Den Themen \emph{Virtualisierung} und der autom. \emph{Bereitstellung} sowie \emph{Freigabe}
von Ressourcen (\emph{Provisioning \& Deprovisioning}), gewähren wir in den beiden nächsten
Kapiteln besondere Aufmerksamkeit. Das Thema \emph{Datensicherheit} wird seiner Bedeutung wegen in
Kapitel \ref{} gesondert umfassend behandelt.

\subsection{Virtualisierung}\label{sec:cc:risks:virtualisierung}
Um Risiken der Virtualisierung zu erkennen, gilt es zunächst zu verstehen, wie Virtualisierung
funktioniert. Konkret ist an dieser Stelle die Virtualisierung von Rechnern oder Betriebssystemen
gemeint. Es existieren eine Reihe unterschiedlicher Virtualisierungstechnologien, die allesamt in
der Praxis Verwendung finden. Sie unterscheiden sich im \emph{Virtualisierungsgrad} und stellen
daher verschiedene Anforderungen an das \emph{Gastbetriebssystem} (Gast OS). Einige der Technologien
lauten:
\begin{itemize}
  \item \textbf{\emph{Vollvirtualisierung}}\\
  Bei der Vollvirtualisierung simuliert ein \emph{Hypervisor} wichtige Hardwarekomponenten.
  Diese Komponenten reichen aus, um ein Gast OS ohne jegliche Modifikationen auf einer VM
  laufen zu lassen.
  \item \textbf{\emph{Paravirtualisierung}}\\
  Der Hypervisor stellt bei der Paravirtualisierung nur wenige oder gar keine simulierten
  Hardwarekomponenten bereit. Stattdessen werden Systemaufrufe eines Gast OS an spezielle APIs
  gereicht. Sie landen beim Hypervisor, der die Aufrufe an das \emph{Wirtsbetriebssystem}
  weiterreicht oder direkt selbst auf der Hardware verarbeitet. Man nennt jene Systemaufrufe daher
  auch \emph{Hypercalls}. Alle Gastbetriebssysteme müssen modifiziert werden, bedingt durch die
  APIs, in denen sämtliche Systemaufrufe münden.
  \item \textbf{\emph{Betriebssystemvirtualisierung}}\\
  Bei der Betriebssystemvirtualisierung teilen sich Wirts-- und Gastbetriebssysteme einen
  \emph{gemeinsamen} Betriebssystemkern. Anwendungen die in einem Gastsystem ausgeführt werden  
  sind isoliert und sehen z.B. nicht die Anwendungen des Wirtsystems. Die Bezeichnungen
  \emph{Container OS} oder \emph{Jails} (quasi ein Gefängnis für die Anwendung) haben hierdurch
  ihren Ursprung. Der gemeinsame Betriebssystemkern fungiert im logischen Sinn demnach als
  Hypervisor.
\end{itemize}
Neben den gerade vorgestellten Virtualisierungstechnologien, kann noch zwischen \emph{Typ--1} und
\emph{Typ--2} Hypervisors differenziert werden. Ein Typ--1 Hypervisor läuft direkt auf der Hardware,
während ein Typ--2 Hypervisor als spezielle Applikation auf einem Wirtsbetriebssystem ausgeführt
wird. 

Abbildung \ref{figure:sunvirtua} stellt exemplarisch die Sun xVM Virtualisierungslösung vor.
Es kommen hierbei unterschiedliche Virtualisierungstechnologien zum Einsatz.

\begin{figure}[h]
\centering{
\scalebox{0.75}{\includegraphics{./img/sun-virtualization.png}}}
\caption[Sun xVM ]{Der Sun xVM Hypervisor. Quelle: \cite{mkl-cloudsecprivacy-09}}
\label{figure:sunvirtua}
\end{figure}

Vergegenwärtigen man sich die gerade vorgestellten Grundlagen der Virtualisierung, wird schnell
ersichtlich, dass der Hypervisor ein lohnendes Ziel für Angriffe darstellt. Ein kompromittierter
Hypervisor hätte nämlich zur Folge, dass alle ihm zuzuordnenden VMs ebenfalls kompromittiert wären.
Läuft auf jeder physischen Maschine der gleiche Hypervisor, wovon in einer homogen geprägten Cloud
Infrastruktur auszugehen ist, würde viele Sicherheitskontrollen ausgehebelt und Daten der
Cloud--Nutzer wären wohlmöglich nicht mehr isoliert --- aus den einzelnen Sandkästen wird eine frei
begehbare Wüste. Glücklicherweise bietet ein Hypervisor nur eine vergleichsweise kleine
Angriffsfläche, die ein böswilliger Cloud--Nutzer ausnutzen könnte. Ein Hypervisor ist für den
normalen Netzwerkverkehr nämlich nicht nur völlig unsichtbar, er ist auch wesentlich kompakter als
ein modernes Betriebssystem und führt selbst keinen potentiellen Schadcode aus. Auch wenn ein
Hypervisor demnach ein hohes Gefahrenpotential birgt, Schwachstellen tatsächlich auszunutzen
gestaltet sich als schwierig.

Eine weiteres Risiko geht von Cloud Services wie Amazon's \emph{Elastic Block Store}\footnote{Für
Informationen zum EBS Service siehe: \url{http://aws.amazon.com/de/ebs/}.} (EBS) aus.
Zwar sind solche Blockspeicher logisch einem AWS--Kunden zuzuordnen, technisch liegen diese
virtuellen Datenträger allerdings in redundanter Ausführung auf mehreren Festplatten vor. Die
\emph{Reallokation} derartiger Ressourcen durch VMs unterschiedlicher Kunden, kann früher oder
später zu \emph{Information Exposure} führen. Folglich ist es wichtig, datentragende Ressourcen vor
dem Freigeben zu bereinigen. In einer IaaS oder PaaS sollte sich der Kunde dabei nicht auf den CSP
verlassen, sondern stets zusätzlich die eigene Löschkeule schwingen.

Der Isolation der VMs gilt es besondere Aufmerksamkeit zu schenken. Public Clouds mit einer Vielzahl
von Benutzern, machen Angriffe aus dem internen Netzwerk schließlich nicht unwahrscheinlicher. Dabei
ist die Gefahr, die von VMs auf der gleichen physischen Maschine ausgeht, größer als jene
zwischen beliebigen VMs der Cloud. \emph{Intrusion Detection Systeme} (IDS) haben einen schweren
Stand Angriffe aufzuspüren, die nicht in einem \glqq richtigen\grqq{} Netzwerksegment stattfinden.
Ausgewachsene Hypervisor sind deshalb auch in der Lage, Netzwerkkomponenten zu simulieren. Paket--
und Verbindungsfilter der Gastbetriebssysteme bieten zusätzlichen Schutz. Es gilt aber zu bedenken,
dass die automatisierten Skalierungsmechanismen nicht nur die Anzahl der VMs beinflussen können,
sondern ggf. auch freie IPs neu vergeben.

Einen weiteren Beitrag zur Isolation leisten \emph{VLANs}. Sie separieren durch virtuelle
Teilnetze den Daten-- und Kontrollfluss der VMs unterschiedlicher Cloud--Nutzer.
\emph{Eucalyptus}\footnote{http://open.eucalyptus.com/}, im Prinzip eine Open Source Variante
einiger Amazon Web Services, bietet die Isolation auf OSI Layer--2 und Layer--3 Schicht, als einen
wesentlichen Sicherheitsmechanismus an. Im sogenannten \emph{Managed} Netzwerkmodus verwaltet der
\emph{Cluster Controller}, eine Softwarekomponente den ein physisches Teilsegment der Cloud
untersteht, virtuelle Maschinen mit Hilfe eines eigenen DHCP--Servers. Zusätzlich wird jede laufende
VM--Instanz emit einer \emph{Security Group} assoziiert. Hierbei sorgen umfangreiche Firewallregeln
dafür, dass nur VMs innerhalb einer Security Group untereinander sichtbar sind.
\subsection{Provisioning \& Deprovisioning}
\emph{(Anmerkung: um in Zukunft Missverständnisse und Doppeldeutigkeiten zu vermeiden, wird von nun
an nicht mehr von der \emph{Bereitstellung} oder \emph{Freigabe} von Ressourcen gesprochen. 
Stattdessen verwende ich die eindeutigen Begrifflichkeiten \emph{Provisioning} und 
\emph{Deprovisioning}.)}
\bigskip

Die Cloud würde ohne das automatische Provisioning nicht funktionieren. Der Benutzer erwartet, dass
die von ihm benötigten Ressourcen schnell und zuverlässig zur Verfügung stehen. Weil sich Ressourcen
dabei häufig über mehrere Instanzen und Datenzentren erstrecken, wird sogleich die
\emph{Ausfallsicherheit} und \emph{Verfügbarkeit} erhöht. Doch diesen beiden Vorteile werfen auch
die Frage auf, wie Cloud Provider die Daten und Applikationen ihrer Kunden konsistent halten. IaaS
Clouds wälzen das Problem der \emph{Versionskontrolle} gerne auf die Benutzer ab, doch in jeder
Cloud gibt es Services, um die sich der CSP zu kümmern hat. Hierzu zählen die
Sicherheitskontrollen-- und mechanismen wie Logging, Authentifikation oder die
Datenverschlüsselung. Der Provider muss sich auch um die Integrität und Aktualität seiner VM Images
sorgen. Nachlässigkeit kann hier schlimme Folgen haben. Alte Betriebssystemversion und Anwendungen
weisen nicht selten unmengen an Schwachstellen auf, die Angreifern als auch anderen Cloud--Nutzern
Tür und Tor öffnen.

Grundsätzlich gilt dem Provisioning und Deprovisioning besondere Aufmerksamkeit. Es handelt sich um
\emph{atomare} Operationen die sowohl korrekt, als auch vollständig ablaufen müssen. \emph{Privilege
escalation} ist bei wiederverwendeten IDs und IPs ein immerwährendes Risiko und wie schon in Kapitel
\ref{sec:cc:risks:virtualisierung} erwähnt, sind durch andere VMs reallokierte Ressourcen immer auch
ein Schlupfloch für ungewollten Informationsaustausch.

\include{data_security}

\section{Sichere Cloud Architekturen \it \bfseries \tiny SP}
Dieses Kapitel beschäftigt sich mit Cloud Infrastrukturen, die auf Basis ihrer Architektur ein
gewisses Maß an Sicherheit bieten. Als Quellen dienten \cite{winkler-seccloud-11,
mkl-cloudsecprivacy-09} und \cite{ts2-vergleichsicherheit-10}.

\subsection{Anforderungen an die Architektur}
Bevor Kapitel \ref{sec:secc:concepts} auf konkrete Sicherheitsmaßnahmen eingeht, gilt es zunächst zu
verstehen, welche mannigfaltigen Anforderungen das Cloud Paradigma an Service Provider und
Unternehmen stellt. Insbesondere Public Clouds erfordern ein großes Maß an Sorgfalt, die in
\emph{Planung} und \emph{Design} einfließen sollte. Bedenkt man die Kosten, mit denen der Bau eines
ausgewachsenen Datenzentrums einher geht, so wird klar, dass schon kleinste Planungsfehler
horrende Zusatzkosten verursachen können.

Den Anfang machen Policies und Standards, an denen sich der zukünftige CSP i. d. R. zu halten hat.
Sie definieren was tatsächlich als Gefahr einzustufen ist und geben vor, wie bestimmte
Sicherheitsmechanismen implementiert werden. Auf diese Weise wird bereits eine Grundlage für die
Anforderungsanalyse geschaffen. So trifft die Security Policy eine detaillierte Aussage darüber, wer
wie über bestimmte Kanäle auf klar definierte Ressourcen zugreifen darf. Service Level Agreements
mit Kunden, wie auch rechtliche Vorschriften, stellen zudem weitere Anforderungen an die
Architektur.

Ein wichtiger Aspekt, der beim Bau eines Datenzentrum häufig zu wenig Aufmerksamkeit erhält,
ist die der \emph{physikalischen Sicherheit}. Alle Sicherheitskontrollen auf Softwareebene sind
schließlich wirkungslos, wenn sämtliche Hardwarekomponenten ansonsten völlig ungeschützt sind. 
Eine Absicherung gegen die große Bandbreite physikalischer Bedrohung ist jedoch kostspielig und
erklärt die Zurückhaltung vieler Unternehmen. Geschultes Personal, umfassende Zugriffskontrollen,
ausgelagerte Backups --- um an dieser Stelle nur einige Beispiele zu nennen --- müssen
\emph{regelmäßig} geprüft und ggf. ausgebessert werden, um die vorgegebenen Sicherheitskriterien zu
erfüllen. Es gilt wie schon in der Software-- bzw. Informationssicherheit:
die Kette ist nur so stark wie das schwächste Glied.

Tabelle \ref{table:req} enthält einige der gängigsten Sicherheitsanforderungen im Cloud Computing.

\begin{center}
\begin{table}[h]
\begin{tabularx}{\textwidth}{>{\vspace{0.3em}\bfseries\columncolor{darkgray}}p{4cm}<{\vspace{1em}} 
>{\vspace{0.3em}\columncolor{lightgray}}X<{\vspace{1em}}}
Anforderung & \textbf{Beschreibung} \\ \hhline{==}

\emph{langer Text} & 
Eine Absicherung gegen die große Bandbreite physikalischer Bedrohung ist jedoch kostspielig und
erklärt die Zurückhaltung vieler Unternehmen. Geschultes Personal, umfassende Zugriffskontrollen,
ausgelagerte Backups --- um an dieser Stelle nur einige Beispiele zu nennen --- müssen
\emph{regelmäßig} geprüft und ggf. ausgebessert werden, um die vorgegebenen Sicherheitskriterien zu
erfüllen. Es gilt, wie schon beim Counterpart (der Software-- bzw. Informationssicherheit):
die Kette ist nur so stark wie das schwächste Glied.\\

langer Text & 
Eine Absicherung gegen die große Bandbreite physikalischer Bedrohung ist jedoch kostspielig und
erklärt die Zurückhaltung vieler Unternehmen. Geschultes Personal, umfassende Zugriffskontrollen,
ausgelagerte Backups --- um an dieser Stelle nur einige Beispiele zu nennen --- müssen
\emph{regelmäßig} geprüft und ggf. ausgebessert werden, um die vorgegebenen Sicherheitskriterien zu
erfüllen. Es gilt, wie schon beim Counterpart (der Software-- bzw. Informationssicherheit):
die Kette ist nur so stark wie das schwächste Glied. \\
\label{table:req}
\end{tabularx}
\caption{Test}
\end{table}
\end{center}

\subsection{Security Monitoring}

\subsection{Wichtige Sicherheitskomponenten \& Security Pattern}\label{sec:secc:concepts}

\subsection{Architektur am Beispiel}

\newpage
\nocite{*}
\addcontentsline{toc}{section}{Literatur}
\bibliographystyle{alphadin}
\bibliography{literatur}
\pagebreak

\end{document}
